System-of-Systems Design From An Object-Oriented Paradigm

Safety critical interactions increase as the complexity of highly integrated systems increases. In complex systems and systems-of-systems, these possible combinations are practically limitless. System “unravelings” have an intelligence of their own as they expose hidden connections, neutralize redundancies, bypass firewalls, and exploit chance circumstances for which no system engineer might plan. A software fault in one module of the system software may coincide with the software fault of an entirely different module of the system software. This unforeseeable combination can cause cascading failures within the system. In this paper, we will offer a new paradigm for system-of-systems development using a hypothetical missile defense system as a case study. Rather than decompose each system within the missile defense system in the traditional functional fashion, we will treat the system-of-systems as a single entity – a system – that is comprised of various abstract classes. We will identify the common problems and shortcomings that system engineers address in the design and development of system-of-systems. The object-oriented paradigm offers a new system-of-systems requirements and design methodology that can minimize accidental complexity and control essential complexity through the object-oriented concepts of decentralized control flow, minimal messaging between classes, implicit case analysis, and information-hiding mechanisms. The greatest source of system software faults will occur in the integration of the various systems. With respect to our case study, the hypothetical missile defense systems will be a complex product that will contain many discrete software packages within each system. As a rule, these software packages will be developed independent of each other and programmed in many different languages. Additionally, the hypothetical missile defense system will include legacy systems that are currently in operation. The means of integrating these elements and legacy systems are intricate tactical data links that support the message transfer within the system-of-systems. While the hypothetical missile defense system will not be a pure object-oriented design, we can incorporate many of the principles of object-oriented technology to decrease the complexity of the system-of-systems. We believe that software engineers of system-ofsystems can use this object-oriented paradigm to produce a sound design for the systemof-systems rather than the traditional federation of systems through a highly coupled communication medium. Proc. Monterey Workshop: Radical Innovations of Software and Systems Eng. in the Future, US Army Research Office (Venice, Italy, Oct. 2002). 2 Introduction. During the past decade, systems-of-systems have exploded into the battlespace of the joint and coalition warfighters. The acquisition community’s response to the rabid craving for more accurate information and more lethal functionality has been a less than stellar hobbling of various legacy systems and ongoing system developments through tightly coupled and lowly cohesive communication shackles. While there are many issues with system-of-systems acquisitions, the first issue that we must address is the requirements definition and allocation issue. Just as the requirements issue continues to plague single system acquisitions, the requirements issue is much more complicated in the system-of-systems acquisition. For example, a good number of the systems that comprise the system-of-systems are legacy systems and currently operate as stand-alone capabilities in the operational world. We developed these legacy systems with specific sets of requirements and with specific system functionality in mind. Additionally, just as we developed the legacy systems, we are developing new systems that will become a member of a system-of-systems under similar conditions. That is, we are developing these systems as stand-alone capabilities with specific sets of requirements and with specific system functionality in mind. Now comes the desire to slam these various systems together and connect these systems through some communication medium in the hope of achieving greater functionality (i.e. the whole will be greater than the sum of its parts). We identify the systems that will form the system-of-systems, and we set out to bend, fold, spindle, and mutilate these systems in the fevered hope of producing a functional composition. Oftentimes, it is very difficult to think about the system-of-systems as a single entity so we mistakenly focus on modifying individual systems with little deliberation and consideration for the whole. Our tools for reasoning about a system-of-systems typically consist of little more than a “sticks and circles” diagram. The “circles” represent the various systems that comprise the system-of-systems while the “sticks” are means of information transfer, a messaging protocol, and, perhaps, a translator box to translate the messaging format from one system to another. Armed with this sophomoric view of the system-of-systems, we attempt to analyze and describe the system-of-systems through a trivial picture of the various systems as connected by a convoluted labyrinth of lines. Traditionally, this methodology failed to achieve an interoperable and integrated systemof-systems. With each new failure, the system engineers attempted to “tighten up” the protocol standard; however, the system-of-systems did not achieve the desired degree of interoperability and integration. The end-state is a collection of systems that are tightly coupled with a realized protocol standard that only serves to greatly increase the systemof-systems software complexity. As we have witnessed time and again, system software critical interactions increase as the complexity of highly integrated systems increases. In the complex system-of-systems, these possible combinations are practically limitless. System “unravelings” have an intelligence of their own as they expose hidden connections, neutralize redundancies, bypass firewalls, and exploit chance circumstances for which no system engineer might Proc. Monterey Workshop: Radical Innovations of Software and Systems Eng. in the Future, US Army Research Office (Venice, Italy, Oct. 2002). 3 plan. [1] A software fault in one module of the system software may coincide with the software fault of an entirely different module of the system software. This unforeseeable combination can cause cascading failures within the system. How do we reason about such a structure so that we have at least a modicum of chance to realize a functional system-of-systems? Can we extend the existing set of tools that we use in reasoning about a single system development to the more complex system-ofsystems development? If true, can we use these tools to identify potential sources of accidental system software complexity? We propose that applying the Unified Modeling Language (UML) and object oriented design (OOD) techniques to the system-of-systems requirements analysis offers a new model for reasoning about complex system-of-systems developments. Rather than disparate reasoning about the individual systems of a proposed system-of-systems, we propose that we develop a sound model for reasoning about the system-of-systems as a single, functional entity. We will propose this new paradigm through an example of a hypothetical missile defense system. As depicted below in Figure 1, missile defense systems are most often analyzed and described by the sticks and circles diagram. It is difficult to reason about requirements and analyze the system-of-systems with the hypothetical missile defense system-of-systems sticks and circles view. Although presented as a single entity, it is challenging to understand the affect of requirements changes and component limitations in this view. As previously mentioned, our reasoning BattleManager1 BattleManager2 BattleManager3